Ethernet-Shared Protection Ring (“E-SPRing”), as standardized according to International Telecommunication Union (“ITU”) specification ITU-T G.8032, defines an effort to provide sub-50 ms protection for Ethernet traffic in a ring topology while simultaneously ensuring that no loops are formed at the Ethernet layer. Using the E-SPRing standard, there is a central node called the Ring Protection Link (“RPL”) owner node which blocks one of the ports, known as the RPL port, to ensure that no loop forms for the Ethernet traffic. Ring Automated Protection Switching (“R-APS”) messages are used to coordinate the activities of switching the RPL link on or off.
Any failure along the ring triggers an R-APS Signal Fail message, also known as a Failure Indication Message (“FIM”), along both directions from the nodes adjacent to the failed link after these nodes have blocked the port facing the failed link. On obtaining this message, the RPL owner node unblocks the RPL port. Because at least one link has failed somewhere in the ring, that there can be no loop formation in the ring. During the recovery phase, when the failed link gets restored, the nodes adjacent to the restored link send RAPS No Request messages, also known as a Recovery Indication Messages (“RIM”). Upon obtaining a RIM message, the RPL owner blocks the RPL port and sends an R-APS OK message, which causes all other nodes, other than the RPL owner node in the ring to unblock all blocked ports.
The E-SPRing protocol is robust enough to work for unidirectional failure and in case of multiple failures in the ring. However, there is currently no mechanism provided by the E-SPRing protocol, i.e., ITU-T G.8032, to determine the actual Ring Topology, i.e., the nodes and links that form the ring.
Ring topology is required to perform ring topology validation. In other words, when a service provider provisions and/or configures a ring, a tool is needed to validate that the actual configuration is what was expected. In addition, if/when a ring failure occurs, the service provider or repair technician has no convenient means to determine exactly where the fault occurs.
Additionally, when a fault or topology change occurs, each node temporarily clears or “flushes” its current Forwarding Database (“FDB”), a table which contains the routing configuration from the point of view of the current node. If data arrives at a node for forwarding during the time interval between the FDB flushing and establishing a new FDB, the node does not know exactly how to forward the data. In this case, the node simply “floods” the ring by forwarding the data through each port resulting in poorer ring bandwidth utilization during a ring protection and recovery event.
Therefore, what is needed is a method and system for discovering the topology composition of Ethernet rings and to update data forwarding tables upon Protection and Recover switching without flooding the network.